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Geen 



MOVE, een flexibele en uitbreidbare architectuur voor hoge prestatie processor ontwerp 



^7) Afgelopen decennium zagen we een algemene acceptatie van de RISC-ontwerp-principes. Om nog betere pres- 
taties te verkrijgen, Is veel onderzoek gericht op het ontwikkelen van archltecturen die instructieniveau-parallel- 
lisme exploiteren. Twee eigenschappen onderscheiden deze architecturen: 1. hoe wordt parallellisme gedetec- 
teerd (statisch of dynamisch), en 2. hoe wordt het geYmplementeerd (pipelined versus meerdere functie- 
eenheden). Deze architecturen hebben echter een aantal nadelen wetke resuiteren in een compiexe organisatie 
en inefficient gebruik van hardware. VLSI wordt niet tot de uitersle grenzen geexploiteerd wat betreft optimale 
cyclustljd, en verder hebben deze architecturen onvoldoende flexibiliteit voor het op eenvoudige wijze genereren 
van applicatie-speclfleke-processoren. 

Ter vermijding van bovengenoemde nadelen hebben wij een architectuur uitgevonden die eenvoudig te maken 
is, de beschikbare hardware efficienter gebruikt, optimale cyclustijd toeiaat. en die eenvoudig te reconfigureren is 
voor andere functionalitelt en prestatie. Naast bruikbaarheid voor algemene berekeningen, is deze architectuur 
bi]zonder geschikt als raamwerk voor het semi-automatisch genereren van processoren voor applicatie-speci- 
fieke-doelelnden waar zeer hoge prestaties vertangd worden. 

De essentie van deze uitvinding is een architectuur weike het datatransport volledig scheidt van de operaties op 
deze data, waardoor de aanwezige transportcapacKeit veel beter gebruikt wordt. Deze scheiding geeft onder 
andere zeer veel vrijhekl aan de Implementatie van functie-eenheden; zo kunnen verschtllende pipelining-sche- 
ma's door elkaar gebruikt worden. Verder kunnen we de cyclustijd reduceren tot het absolute minimum, namelijk 
de tijd benodigd voor het transport van data. Het resuherende programmeermodel Is ongebruikeltjk en geeft 
scheduling-mogelijkheden weIke in voorgaande architecturen niet voorkomen. 
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^ De aan dit blad gehechte afdruk van de beschrijving met conclusie(s) en eventuele tekening(en) bevat atwijkingen ten 
_j opzichte van de oorspronkelijk ingediende stukken; deze laatste kunnen bij de Octrooiraad op verzoek worden 
Z tngezien. 



SDOCID: <NL 910059BA_L> 



1 



MOVE: Een Flexibele en Uitbreidbare Architectuur voor het Ontwerpen van 

Processoren 

1 Inleiding 

Een van de meest belangrijke ontwikkelingen in het ontweip van computer systemeri was het gebruik van 
RISC- i.p.v. CISC-ontweipprincipes [1]. De belangrijkste les was. dat extra hardware (bijv. voor het 
implementeren van complexe instructies) niet altijd resulteert in snellere executie; in tegendeel, het kan de 
totale executie tijd doen toen^en. Mogelijke ooizaken hiervoor zijn: 

5 

1 . Extra hardware functionaliteit kan het kritieke tijdspad vcrgroten, hetgeen tot een veiiioogde cyclustiid 
leidt. ^ J J 

2. Complexe instructies worden in algemene berekeningen zelden gebniikt Hardware hieraan besteedt 
kan wellicht effectiever voor andere veibeteringen aangewend worden. 

10 3. Cdmplexe instnicties zijn moeilijk te pipelinen. 

4, Soms zijn software opiossingen voor complexere instracties zelfs sneller dan de overeenkomstige 
hardware oplossing; i.h.b. indien compiler optimalizaties de software oveihead voor een deel elimi- 
neren. 

5. Cbmplexe hardware veihoogt de ontwikkeltijd en maakt daardoor het gebruik van de laatste techno- 
1 5 logische verbeteringen onmogelijk. 

Afgezien van deze ooizaken, vennindeit de implementatie van complexe ftmcties de ontweip-flexibiliteiL 
Deze functies kunnen het ontwerp zodanig bepalen, dat het aanbrengen van toekomstige veibeteringen 
lastig wordt. 

20 Momentecl leveren de meeste CPU-fabrikanten op RlSC-principes gebaseeixie computereystemen met ver- 
gelijkbare prcstaties. De prostatic wordt gcdominecrd door de gebruikte technologic. Daar de basis 
complexiteit van een RISC-processor tainelijk bepeikt is, kan deze eenvoudig worden geintegreerd in een 
VLSI-oniweipomgeving voor de creatie van applicatie-specifieke-processoren ([2]). Theoretisch haalt een 
RISC-systeem een prestatie van 1 CPI (cyclus per instnictie); in de praktijk is deze iets groter t.g.v. penal- 

25 ties veroorzaakt door load en branch opdrachten. Efficient gebruik van RISC-systemen vereist compilere 
welkc in staat zijn deze penalties te minimalizercn d.m.v. het plaatsen van instructies in delay slots; dit 
kan beschouwd worden als een bepeikte vorm van scheduling van parallelle instnicties. 

Ter verkrijging van een nog grotere performance veibetering, dan alleen met snellere technologic mogelijk 
is, onderscheiden we twee belangrijke architectuur-techniekcn: 1) het gebniik van diepe pipelines, en 2) het 
30 gebmik van meerdere onaftiankelijke ftmctie-eenheden (FUs). De eerete techniek reduceert de cyclustijd, 
de twecde de CPL Beide technieken vereisen uitgebreide parallellizatie van code op het instructie-niveau. 
De volgende sectie bespreekt deze ontwikkelingen. Tevens wordt veiklaart waarom de resulterende archi- 
tecturen een aantal nadelen hebben, welke hun toepasbaarheid steik beperken. 

De hier beschrcven uitvinding betrcft een zeer afwijkende architectuur, genoemd de MOVE-architectuur, 
welke het data-transport en de data-operaties volledig scheidt. Sectie 3 beschrijft deze uitvinding terwijl 
sectie 2 de recente architectuur-ontwikkelingen en de MOVE-concurenten beschrijft. Sectie 4 vergelijkt 
de MOVE-architectuur met deze concurrerende architectuur-implementaties en toont de superioriteit van 
de beschrcven uitvinding. Sectie 5 bevat de conclusies, sectie 6 de figuren en de laatste sectie bevat een 
veiklarcnde woordenlijst en een bibliography. 

9 10 0 5 9 8 
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2 Recente Architectuur-ontwikkelingen 



Om de snelheid van enkelvoudige processoren te veihogen woiden verschillende architectuur-technieken 
toegepast [3], te weten: 

5 

Superpipelining: Het opdelen van bestaande pipeline stages in sub-stages, waardoor een koiteie cyclustijd 
mogelijk wordt. Dit is een uilbreiding van het RlSC-prpe/ine-principe; daar besloeg de executie- 
stage nog 1 cyclus, tenvijl deze nu wordt opgedeeld in meerdere stages. Superpipelining zal de 
eifectieve CPI iets vcrgrotcn tengevolge van het toegenomen aantal delay slots^ echter dit effect 
10 wordt gecompenseeid door de verlaagde cyclustijd. Voorbeelden zijn te vinden in [4^]. 

Functioneel parallellisme: Door het toevoegen van onafhankelijke iunctie-eenheden t^ exploitatie van 
het operatic parallellisme heeft als gevolg dat de effectieve CPI lager wordt dan €€n. Superscalars 
[6,7] en VUWs [8,9,10»11,12] zijn vertegenwoordigers van het toepassen van deze techniek. Supers- 
calars passen dynamische detectie van operatie-parallellisme ioe» terwijl VLTWs dit volledig door 
15 de compiler (statisch) laten doen. Hoewel Superscalars ter verkrijgen van een redelijke effici€nte 

executie ook intensieve compiler ondersteuning vereisen, kunnen zij ook niet-geschedulede code uit- 
vberen; zij kunnen daardoor object-code compatibel zijn met architecturen die niet met functioneel 
parallellisme zijn uitgevoerd. 



20 Superscalars hebben een sterke bepeiking in de hoeveelheid te exploiteren parallellisme. De hardware 
nodig voor runtime parallellisme-detectie bepeikt de grootte van het decode-window tot een paar instructies. 
Verdere hardware reductie is mogelijk door het aantal mogelijk te combineren instmcties te beperken (bijv. 
maximaal 1 integer, 1 drijvende-komma, 1 load/store en 1 controle-instractie). De compiler is veel beter 
in staat om mogelijke parallelle-instructies te ontdekken dan met hardware ooit mogelijk is (een mogelijke 

25 uitzondering is het detecteren van adres-afhankelijkheden bij geheugcn-operaties). Een gunstig gevolg van 
dynamische detectie is wel, dat de grootte van de code niet toeneemt t.g.v. het invoegen van lege instructies 
(NOPs). Kortom, superscalars zijn goed voor bepeikte piestatie veibeteringen van bestaande systemen, 
maar vereisen hicrvoor wel compiler support. 

VUW' en Sigyerpipelined-^clutccturcn hebben een hoger potentieel m.b.t. parallelle executie dan Supers- 
30 calars. Het voordeel zal voor scalaire applicaties bepeikt zijn (i,v.m. de sequentiele aaid van de bereke- 
ningen); echter voor specifieke- en vector-applicaties kan een veel grotere snelheidstoename gerealiseerd 
worden. 

Idealiter willen we VUW- en Superpipelining-icchniekcn combineren. Dit zou een architectuur opleveren 
die hoge vector-prestaties levert, die geschikt gemaakt kan worden voor specifieke-applicaties en ook nog 
35 een goede scalaire-prestatie laat zien. Echter, zoals we zullen aantonen in sectie 4, bezit deze architectuur 
een aantal nadelen welke resulteren in een complexe-organizatie, inefficient hardware gebruik, mocilijk te 
wijzigen fimctionaliteit, en beperktc uitbreidbaaihcid. Daardoor is zij niet ideaal voor gebniik in een raam- 
weik voor applicatie specifiek processor ontwerp. De uitvinding welke beschreven wordt in de volgende 
sectie heeft deze nadelen niet. 

40 

3 De MOVE-architectuur 



De vereiste prestatie, en de toegestane ontweip en fabricage kosten bepalen voor VLIW het aantal en 
type en voor Superpipelined de diepte en type van de te gebruiken functie-eenhedeiL De communicatie- 
45 bandbreedte tussen fimctie-eenheden wordt uitsluitend bepaald door het aantal en type functie-eenheden; 
zij dient op de worst-case situatie berekend te zijn. Evenzo is de instructie-bandbreedte afgestemd op de 
worst-case situatie, n.l. dat alle functie units tegelijkertijd in gebruik zijn. Zelfs indien dit het geval is, zal 
de vereiste conununicatie-bandbreedte zelden worst-case zijn. 

9 10 0 5 9 8 

5DOCID: <NL ^910059aA_l_> 



3 



10 



In deze seaie beschrijven we een uitvinding van een architectuur (de MOVE-architectuur), die boven- 
genoemde proWemen van overdesign stcik reducceit. In de volgende subsectie ontwikkeloi we dezc 
architectuur vanuit het gezichtspunt van VLIW en Supeipipelining architecturen. Vervolgens woiden za- 
kcai als pipelining, het aihandelen van excepties, en de benodigde ondereteunings-mechanismen, nodig 
voor een efficiSite afbeelding van Iwgcrc programmeeitalen en operating-systemen, besproken. 

3.1 Van VLIW en Superpipelining naar MOVE 

Indien we VLIW en Supeipipelining als vertrekpunt kiezen, kan de ontwikkeling van de MOVE-arehitectuur 
als een 6-staps proces worden gezicn: 1) reductie van register-file comnninicatie-bandbreedte. 2) het 
programmerMi van de bypass, 3) het reduccren van de &3!PflJi-conncctiviteit, 4) het separerai van transport 
cn opcratie, 5) reductie van de tranport capadteit en 6) het programmercn van het transpoit 

Reductie van de register-lile-comniunicatie-bandbreedte Rguur la toont de interne communicaUe- 
structuur van een {super-) pipelined organizatie. Een set van functie-eenheden (FUs) is verbonden met 
een bypass-eenheid welke operand- en bypass-registers bevat De bypass-eenheid is veibonden met een 
register-file. Op sooitgelijke wijze toont figuur lb de communicatie-stnictuur van een VUW. Deze VLIW 
oiganizatie woidt in het vervolg als uitgangspunt gebraikt. 

De bypass bevat naast operand-registers, een aantal bypass-registers voor tijdelijke resultaten. Deze laatste 
zijn georganizeerd als FIFOs. De operand-registers lezen hun data uit de register-file, de FIFO, of de 
uitgangen van de FUs. Het schrijven van resultaten kan in alle FIFO registeis geschieden. afhankelijk van 
de tijd die een FU-operatic duurt Dit schrijven gaat veigezeld van het schrijven van de K&ster-identifier. 
Deze identifier dient voor het schrijven in de register-file en voor identificatie van de tijdelijke resultaten 
in de bypass. Een resultaat welke de FIFO veriaat wordt in de register-file geschreven. De bypass is niet 
25 zichtbaar op architectuur niveau. 

Met respect tot de benodigde bandbreedtc tussen de register-file en de bypass kunnrai we een 2-tal obser- 
vaties geven: 



15 
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1. Mecr dan 50 % van de data in de bypass-registers wordt na het schrijven hiervan in de register-file 
met meer gebruikt. Diepere FIFOs kunnen dit percentages nog verhogen. 

2. Veel instmcties gebniiken niet alle mogelijke register-operanden. Bijv. een branch instractie ge- 
nereeit geen resultaat; monadische instmcties gebniiken maar 1 source-operand. Deze instmcties 
gebruiken dus niet de volledige register-file bandbreedte. 

De compiler kan al deze gevallen van onvolledig gebniik van register-bandbrcedte detecterea We kunnen 
daardoor een organizatie constmeren waaibij het register-transport volledig door de compUer gecontroleerd 
wordt Zoals figuur 2a laat zien. wonit de register-file nu een fiinctie-eenheid met veel minder lees- en 
schrijf-poorten. 



Pro^rammeren van de bypass In de nu gecreeVsrde situatie is het efficienter om de bypass zichtbaar 
te maken op architectuur niveau. De bypass wordt nu een expliciet geadrcsseerd hoogste niveau van de 
geheugen hierarchic. Het schrijven van waarden in de register-file wordt nu niet meer beinvlocd door 
de FIFOs; het is volledig onder controle van de compiler. Alle bypass-registers (vanaf nu inclusief de 
operand-registers) kunnen beschreven en gelezen worden door alle FUs (zie figuur 2b). De vooitlelen 
*>5 hiervan zijn: 

• Eenvoudiger ontweip van de register-file. 

• Eenvoudiger ontweip van de bypass (geen FIFOs, geen identifier matching). 

.9 10 05 98 
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• Kleinere operand-identifier velden in de instnicties. 

ReducUe van de bypass-connectiviteit Daar lezen en schrijven van de bypass-registers onderdeel is van 
de FU-executie, dient dil zo efficient mogelijk te geschieden. £en manier om dit te verwezenlijken is het 
5 reducercn van het aantal connecties en daarmee van de read- en write-load. Toepassing van dit principe 
op de zichtbarc bypass voor het aantal lees- en schrijf-connecties resulteerd in de org^zaties getekend in 
de figuien 2c en 2d resp. 

De eenvoudigste methode ter vermindering van het aantal lees-connecties is het gebruik van prive register- 
sets voor alle FU-ingangen. Deze sets kunnen door alle FUs beschreven worden (zie figuur 2c). De 
10 LIFE-processor [13] gebruikt deze oiganizatie. Ter vermijding van meerdere schrijfipoorten per register-set 
bepeikt LIFE het schrijven per register-set tot 6cn FU per keer. 

Een andere methode is het reduceren van het aantal schrijf-connecties. ledere FU schrijft hierbij in een 
eigen bypass-register. De Cydra-5 [12] gebruikt deze organizatie. Figuur 2d toont een organizatie met 2 
priv6 resultaat registers per FU. 

15 

Separatie van transport en operatie Reductie van zowel het aantal lees- en schrijf-connecties wordt 
geillustreerd in figuur 3a. Alle bypass-registers zijn nu ingedeeld als prive FU-resultaat en FU-operand 
registers. De gehele operatie vindt nu in de FU piaats, het transport daaibuiten. Transport en operatie zijn 
daardoor gescheiden. 

20 

Reductie van transport-capaciteit Het transport-netwerk uit figuur 3a wordt nog steeds niet ten voile 
benut; immers, niet alle FUs zullen iedere cyclus een resultaat aflleveren. De transport-capaclteit van 
dit netwerk moet beter worden afgestemd op geiniddeld gebruik; d.w.z. het aantal bussen moet worden 
gereduceeid (of gelijkwaardig, met hetzelfde aantal bussen kunnen meer FUs bediend worden). Figuur 3b 
23 toont 3 FUs die samoi 2 bussen moeten delen. 

De belangrijkste implicatie van deze organizatie is dat we zowel operaties als transport moeten schedulen, 
Gezien vanuit VLIW gezichtspunt worden de operaties door de compiler (statisch) en het transport-netwerk 
door de hardware (dynamisch) gescheduled. 

30 Programmeren van het tranisport De volgende logische stap is om ook de compiler het tranpoit te 

laten schedulen. De compiler kan hier potentieel een veel bete re prestatie leveren dan de hardware; i.t.t. 
hardware, kan de compiler het gehele programma bekijken. Nu wordt het transport zichtbaar op architectuur 
niveau. Dit betekent dat operaties niet apart gespecificeerd behoeven te worden, zij treden op als zij-effect 
van het transport. Als gevolg is het programmeer-model omgedraaid: 

35 

Traditioneel: Geprogrammeerde operations, operaties triggeren transport. 
MOVE: Geprogrammeerd transport, transport triggert operaties. 



40 De MOVE-architectuur is gebaseerd op dit concept; zij kan worden gezien als een niet-uniforme register-set 
verbonden d.m.v. een point-to-point of point-to-multipoint of ander type netwerk De register-set bevat 
FU-input en FU-output registers, en general-purpose registers. De input-registers zijn verdeeld in 2 types: 
operand- en trigger-registers. Schrijven van data in het trigger-register start een FU-operatie, waaibij de 

^Het gebruik van uitsluitend move-instructies is niet nieuw (zie o.a. [14]). Move-architecturen, waarbij alle functionaliteit 
memory-mapped is, zijn reeds lang bekend. Echter het gebniik van een volledige register-mapped functionaliteit, waarbij meerdere 
guarded tranport-opdrachten parallel kunnen worden uitgevoerd is nieuw. Deze methode leidt tot allerlei verrassende voordelen 
zoals in sectie 4 beschreven. 

9 1 0 0 5 9 8 
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10 Het tnm^rt-netweA kan ecn willekeurige topologie hebben. zolang transport-opdrachten kurmen xvorden 

te opumaluxren voor cen gegeven topologie. Bepeifcte connectiviteit kan de capacitek en daa^S^ 
cycl»sujd veriag«i. HetMOVE-protot^^^ 

een «gul.eie volledig vcrix,nde„ bus-stn.ctuur. waart«j 4 move-opdxachten pandlel woidentritgcS^S^ 
3:2 Pipeline altematieven 

De MOVE-architectuur vereist niet dat de FUs gepipelined moeten worden uitgevoeid. echter optimaal 
FU-gebruJc vereist maximale FU-pipelining. Indien ^ pipeline-latches met lo|ica 2^^^^^^ 
20 we ^' P'P'^'-'-^^S'^ -d"ce..n tot 2. In de praktijk (zie [IsS^Z^XL^TS 

25 ' S^J^clif Z'd"" """^^ ^'"^ ^ *^ P'P"'^^ °P "^Suliere intervanen (meestal iedei. 

mi en t ^'^^/"'^^ ve«choven. Di. is geimplementeenl in de Cydra-5 VLIW 
processor {12] en .n de meeste vector-machines. Dit is eenvoudig te implementerai echter het 
vereist. zoals verderop zal worden aangetoond. veel extra registers. «»enteren. echter het 

. Pushtu Hier wordt de data in de pipeline alleen doorgeschoven in geval een volgende instmctie 
30 ^**^t"»<l'entraditioneleoperaties worden opgesplitst in afzonderlijkemovej. 

* ^I^i!!^ °^'r'"^ ^ """'^ " P'P"^'*™ ""^g doorechuiven. behalve in het 

geval da a aflcomstig van eerdere operaties dreigt oveiBchreven te wonten. doonlat bH v de resuTtat^ 
met optyd zyn gelezcn. Pipeline-stages blokkercn dus zo laat mogelijk. resultaten 

tl^^^'^^TZ^'f^^ ^ ""^"""^ Pipeline-implementatie. De eeme oplossing 

r^Z^vtl f '^'^^^^ ^"^'^^ °P '^^ J^'ste tijd worden gelezcn. Dit vennindert niet alleen de schedMnl 
mogehjkhed«. van de MOVE-machine. doch beteken, veriies van data in geval van ^V^^^l^L 
cache-miss of een excepiic). Dit is niet het geval als de pipeline slechts l-stage dfep 

ISfl'r ^ altematief is iets moeilijker te implementeien omdat stages conditioned mogen doorschuiven 

':^s:^,r'^'''' '''^'-^ ^^^-^ en^extir^ss- 

45 33 Excepties 

Excepties kunncn worden ondervcrdeeld in drie categorien: 

9 1 0 0 5 9 8 
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1. Precies. Het behandelen van deze excepties vcrcist dat dc source-operanden van de operatic die 
aanleiding gceft tot de cxceptie nog vooihanden zijn. Voorbeelden zijn loadSy stores en drijvende- 
komma-operaties (volgens de IEEE 754 floating-point standaard). Na behandeling van*^de exceptie 
moet de executie voortgezet kunnen worden. 

5 2. Niet-precies. Deze excepties vereisen niet dat de source-operanden nog aanwezig zijn voor dc 
behandeling van de exceptie.Ze vereisen echter wel dat de executie na bchandeling voortgezet kan 
worden. Voorbeelden zijn excepties veroorzaakt door integer-arithmetiek^, 

3. Fataal. In contrast met de vorige twee wordt voor deze excq>tie niet de eis gesteld dat execatie 
weer voortgezet moet kunnen wordra. 

10 

Preciese excepties worden gedeeltelijk gcmiplementcerd doonniddel van het gebmik van de zo genoemde 
inexacte exccptie-conditic. FUs proberen zo snel als mogelijk te verifieren of mogelijk een exceptie kan 
optreden. Voordat deze conditie geverifieeid is en ook indien deze conditie waar is, moeten we er voor 
zorgen dat de source-operanden niet worden overschreven. Dit is op vier manieien te realiseren: 1) door 

15 middel van compiler-afsprak«fi, 2) door onmiddelijk locking te initiercn totdat bekend is dat de inexacte 
conditie niet geldig is, of totdat het bekend is dat de exceptie echt is opgetreden, 3) door locking te 
initieren wanneer de source-operanden dreigen te worden overschreven, of 4) door het redden van de 
source-operanden in de FU zelf. Het zal duidelijk dat opiossing 3, samen met cen snelle generatie van de 
inexacte conditie te preferercn is. Voor de meeste FUs uit het MOVE-prototype is dan ook deze combinatie 

20 geimplementeeid. 

Om van een exceptie te kunnen herstellen dient de processor in een staat te woiden gebracht die een 
mogelijk herstel garandeert. Hier zijn grofweg drie methoden voor 1) restart, 2) completion, 3) blocking. 



Restart In het geval van multi-cycli operaties met out-of-order beeindiging is het herstarten (restart) van 
onafgemaaktc instructies praktisch onmogelijk. De PC en overige processor-state dient in dat geval voor 
vde cycli bewaard te blijven, hetgeen een enorme hardware investering vergt. 



Con^Ietion Veel superpipelined en VLIW processoren zijn ontwoipen om na een exceptie die weric- 
zaamheden af te maken waar de verschillende FUs mee bezig zijn (completion). Deze processoren hebben 
30 niet de mogelijkheid de FUs te blokkeren tijdens excepties^. Het gevolg hiervan is, dat al de onafgemaaktc 
instructies na het detecteren van de exceptie alsnog worden afgemaakt. Dit impliceert op zich dat de 
compiler is gedwongcn om de rcsultaat-registers van mulli-cycli operaties niet te gebniiken voor andere 
operaties tijdens de berekening van deze mulli-cycli operatic. In het geval dat excepties precies gedetek- 
teerd moeten worden, wordt dit inefficient register-gebniik alleen maar ergen ook de source-operanden 
moeten nu beschermd worden tegen overschrijving Ujdens de operatic op deze operanden. In de Cydra-5 
[12] garandeert de compiler dit, door een register als m gebruik te verklaren vanaf het begin van de operatic 
tot het moment waarop al de operaties die de geschreven waarde gebniiken afgelopen zijn, Voor loops 
die software-pipelined zijn geeft dit een vrij disastreuse toename in registergebruik. Vergect niet dat al de 
rcgister->i/es in Cydra-5 ontworpen moeten worden voor worstcase situaties. 



35 



40 



Blocking In de MOVE-architectuur blokkeren de FUs vanzelf i.g.v. een exceptie, omdat dit mechanism 
reeds is ingebouwd om een extra graad van scheduling-fLcxibmicit te verkrijgen. De MOVE-pipelines 
blokkeren vanzelf wanneer het resuUaat niet gelezen wordt. Register bestemmingen worden daarom nooit 
overschreven. In feile kan een bestemming niet overschreven worden, omdat de FUs niet weten wat 

^Sommige LISP systemen kunnen preciese excepties voor integer-arithmetiek goed gebniiken. Als gevolg van een overflow 
op fixmwt operaties kan dan de represenUtie naar bignum gewijzigd worden. 

^Een uitzondering hierop is Intel i860 [5]. De pipelines van de i860 moeten doormiddel van duw-en-lrek instructies geleeed 
den. * 
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(buiten hct FU-resultaat register) de uiteinddijke bestemming is. Hct redden en hcrstelien van de FU- 
state kan b.jzonder complex zijn in de huidige VLIWs. Drie redenen hiervoor zijn: 1) stages kunnen 
complexe data fonnaten hebben, 2) bestemming identificatie dient bewaard en he.«eld te kunnen worden 
Soip ? '^«°™'"g-Wentjficatie dient te worden hemeld in de juiste ptpeltne-stage. Voor de 

MOVE-architectuur .s blocking veel makkelijker te implementeren. 1) hct is niet nodig tussemesultaten te 
tewaren. slechts emdresultaten zijn nodig. 2) omdat de instnicties gesplitst zijn in componcnten voor het 
laden van operanden en het lezen van resultaat. is de enige bestemming het FU-resultaat register en is het 
dus met nodig de bestemming-identificaUe te bewaren. 3) aangezien het aantal cycli tussen het starten van 
een operaUe en het lezen van de resultaten niet bepaald woidt door de ¥\3-latency is slechts het herstcUen 
^T^irr I f T belangrijk; de exacte positie m de TU-pipelme is in^levant 

De FU behoeft dus ook gcen complexe organisatie om dit heistel proces mQgeUjk te maken, slechts een 
eenheids-operalie per FU is voldoende om heistel te beweikstelligen (byv. xl. cnz.). 

3.4 Support-mechanismen 

^rtT^^^T r ''T''' """^ ^ gepmgrammeerd door uitsluitend het t,^- 

tTr ondJ^ K ^^'^^^ op deze arehiteetuur vereist een aantal st^port-mechanismen 

ter ondersteunmg van hogere progiammeertalen en operating-systemen. Figuur 4 toont een mogeliike re- 
a^.zat,e van zowel het move- als de support-mechanismen. zoals dit in het pn>totype gerealiseeS fH^t 
Zdrrlrrw ^et transport-netwe^c en de move-identifier-bus. ^4port-mechaln^ 

zijn de guard-, lockmg- en exceptie-mechanismen. 

Conditionele executie Het uitsluitend onderstemien van conditionele executie d.m.v. een compare- en 

hrl™? ' '^"'^.u ^P^' - supeT,ipelined machines. Een betere'^^ak" 

het gebmdc van guards welke conditionele executie van een aanlal of alle transport-operaties Zgdii 

l^TT ^""T"^- ™r ^ guard-seleaor. welke de waamevTee^^ard als c^ndSe 

T^^l I T T T''''^ (boolean-expressie) van deze guanis specifi«ert. De semanSc van een ^ve 
IS zodanig. dat indien de guard false is. de move-operatie geen gevolgcn heeft ^. 

Het guard-mechanisme is geintegreerd in een FU. Deze FU verwcikt de guanl-selector zoals eesoecifi- 
SrellT "f-.-^^'^^'- ^oor iedere gespecificeerde guaid-selector ac^veert de^^ Tc^^n- 

i-P«ementeert tevens de opeiaties voor het zetten van de guards H« 
gua^mechamsme m combinatie met de scheiding van trigger en result move maakt het spSilatkf T 
starten van een FU-operaUe ecnvoudig. Het verwijderen van ongewenste resultaten (eve^eel inclusfef 
ongewenste exceptie conditie) gebeurt in het pn>totype met behulp van een move naar ^^Z^^^r. 

Locking Compile-time synchionizatie van alle move-operaties is niet mogelijk indien Ft7-toe/ic/ej niet 

o^^nldLnr"" "^^^ ^ ^^^^ ^ cache-mL) en is niet efS 

StTw ^ . kmmen worden gevonden om de FU-latency te oveAniggen i.g.v. een RaW-h^. 
Beide problemen worden opgelost door hardware synchronizatie. In het algemeen impUceert synchrari^^ 
da, p«>ducent en consument elkaar kunnen /.c*e«. indien 66„ van tweee^ 

^» tnmsportnetweik uitgtoeid wordt S^tl^Tan' 

S.ti'SSf ^^'iT" '""'I? ' transport-locks: 1) een lees-lock, zolang een resultaat 
(m een FU) nog onderweg ,s. en 2) een schrijf-lock, zolang de FU nog niet beschikbaar is Dc lees- 
lock maakt het schedulen van resultaat-mo ves onafhankelijk van de FU-l!tency.TsS"^cSk 

Fu'Sw^^!,™^"'^^*' ^ P"**"^* geinplememeerd hebben. is dat deze move toch een waarfe uit een 

FU-p,pel„„.teest.dochh,em«eme.sdoe,.enookmogeHjkee.cepHeso«terfn^ 
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efficiente implementatie van preciese excepties toe. Locking verlengt de tijd van de move-operatie zodanig, 
dat deze kan worden voUooid. 



Excepties Het excepiic-suppoit-mechanisme biedt de FU de mogelijkheid 3 types excepties te signaleien 
5 (zie sectie 33). Een herstelbaie exceptie betekent dat de huidige transport-opdracht niet voltooid is, doch 
dat deze na afhandeling van de exceptie kan worden afgemaakt Het trap en return mechanisme hangt af 
van de implementatie van de exceptie-FU. In het prototype wordt gebmik gemaakt van de identifiers op 
de move-identifier-bus, om binnen een cyclus het ad res van de juiste exceptie-routine te kunnen vonnen. 
Dit maakt zeer snelle emulatie van niet geimplementeerde functionaliteit mogelijk. Ten behoeve van 
10 speculatieve executie is het mogelijk om niet-preciese excepties op een later tijdstip af te handelen. Dit is 
mogelijk door het toevoegen van een exceptie-bit aan de data. Het testen van de exceptie conditie vindt 
nu programmatisch plaats. 

4 Vergelijking van MOVE met architectuur trends 

15 

De vorige twee secties beschrijven de recente architectuur ontwikkelingen en ons altematief, de MOVE- 
aichitectuur. In deze sectie vergelijken we deze recente ontwikkelingen met de MOVE-architectuur vanuit 
verschillende gezichtspunten, De belangrijkste reden voor deze vergelijking is de lechtvaardiging van de 
characteristieken van de MOVE-architectuur zoals gepresenteerd in de vorige sectie. Vergelijkingen vinden 
20 plaats op de volgende gebieden: 1) utilizatie van de hardware; 2) geschiktheid voor aanpassing van de 
MOVE naar de eisen van specifieke toepassingen; 3) pipelining van funktie-eenheden; 4) implementatie 
konsekwenties van excepties; en tenslotte, 5) prestatie aspekten zoals snelheid en code-omvang. 

4.1 UtilizaUe van de processor hardware 

25 

Bij het waarderen van de MOVE-architectuur met betrekking tot hardware gebruik, moeten we kijken 
naar de verschillende componenten in een MOVE-processor. Zoals aangegeven in figuur 3a bestaat een 
MOVE-processor uit een transportnetwerk en fiinktie-units. Registers kunnen ook beschreven worden als 
funktie-units, maar we beschouwen deze apart. 

30 

IVansportnetwerk In sectie 3.1 is uitgelegd dat een MOVE-processor de interne transportcapaciteit 
efficienter gebniikt dan een met de MOVE vergelijkbare VLIW. Vergeleken met de VLIW, betekent dit dat 
we met dezelfde hoeveelheid interconnectiemetaal meer iunktie-units kunnen aan spreken en bezig houden. 
Integratie op een enkele chip wordt hierdoor vereenvoudigd, omdat er minder interconnectie overhead is. 

35 

Funktie units Functie-units (FUs genaamd) zijn in de MOVE-architectuur bijna gehcel gescheiden van 
het data-transportnetwerk. De FUs hoeven slechts te voldoen aan een FU-transport interface beschrijving. 
Dit betekent bijvooiteeld dat we de pipelining van functie-units kunnen laten afhangen van de funktie en 
het gebruik. De enige restrictie die opgelegd wordt door het netweric is de tijd tussen het triggeren van 
40 operaties; deze tijd is namenlijk een veelvoud van de data-transporttijd^. 

Register use Het aantal registers benodigd in een MOVE-architectuur kan steik worden venninderd 
vergeleken met andere architecturen. Hiervoor zijn drie redenen aan te geven: 

^it maakt zelfs wavepipelining mogelijk. Wavepipelines vereisen wel dat daU op tijd wordt gelezen uit de pipeline. Onder- 
steuning van excepties betekent dan ook dat de pipeline moct uitlopen in een aantal zg. uiiloop registers. 
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Minder tijdelijke waarden hoeven bewaard te woiden. Veel van deze tijdclijke waarden gaan diiekt 
van FU naar FU zonder in de general-purpose-register geschreven te worden. 
Effectief blijkt, dat PipelinesextXes en FU^perand en FU-rcsultaat rcgistera woiden geb^aikt ter ver- 
vanging van general-purpose-registers. In de MOVE-architectuur woidt ecn gewone RISC-instniktie 
gesphtst in zijn drie fundamentclc transportcomponenten en deze componenten wonlen apart van el- 
kaar gescheduled. Ecn resultaat dat gegenereeid wordt door een FU, maar niet direkt gebmikt kan 
worden (door de zelfde of een andere FU), kan tijdelijk blijvcn staan in de geherercnde FU behalve 
uiteraaid, indicn dit lesultaten blokkeert die eerder nodig zijn. In dit laatste geval is wel een register 
nodig om dit resultaat even te bewaren. Op dezelfde manier kunnen wo een FU-source-regisler 
gebniiken om een waaide tijdelijk in op te slaan voordat de operatie op deze source-operand wonft 
uitgevoeid. 

Blokkerende excepties. Wy hebbcn gekozen voor het automatische Wokkeren van ik^ pipeline-stages 
binnen m een FU wanneer de resultaten nog niet zijn weggehaald. Deze keus heeft tot gevolg dat 
gcen compilatie-strategie nodig is waarin registers voor lange tijd gereserveerd worden. 



4.2 Prestatie 



Voor de prestatieveigelijking kijken we naar: cyclus-tijdbepericingen. scheduling viijheid. code grootte en 
de geschiktheid voor het verweilcen van scalaire en vector toepassingen. 

20 

Cyclustijd De meeste processoren gebaseerd op de RISC-ontwerpfilosofie gebniiken verechillendepferfin^- 
5jja^^s voor het ophalen van instnikties (IF), uitvoeren van de operatie (EX of ALU) en geheugen toegang 
^ /Jt^^^^T ^'^^ Pracessoren wordt nu beperkt door de tijd benodigd voor cache toegang 
(IF ^of MEM) of voor de operatie (ALU). Zowcl cache toegang als operatic kunnen worden gesplitst in 
25 meerdere pipebne-stages {superpipelining). De cache toegang kan opgesplitst wonlen in een decodeer-. 
een opzock- en een M^-vergelijk-jw^e. Het is ook mogeUjk om interleaving op de cache toe te passen 
mdien de opzoek-sMge het kritieke pad in de cyclustijd vomit (de opzoek-^a^e kan kritiek woiden indicn 
te veel cac/ic-hjnen gelezen dienen te worden). 

De operatie-jra^e bestaat uit het lezen van de source-operand-latches, het doorlopcn van de kombinato- 
nsche logica. het dooriopen van de bypass-multiplexers en veivolgens schrijven van een bypass-register 
en eventucel van een source-operand-latch. In principe kunnen we ook een pipeline-latch plaatsen diiekt 
na de logica en voor de multiplexers. Zoals eerder beschreven ([15]), is de minimale hoeveelheid logica 
tuss«i«a^i/,^-registers afhankelijk van hoeveelheid data- en klok-skew. Het verband tussen de schrijftijd 
via de multiplier en de schrijfbelasting is lineair (zie [16]). Deze belasting is evenredig met het aanial 
mgangen van de multiplexer. De schrijftijd wordt dus 0(n) waarin n het aantal multiplexer ingangen is« 
Het schnjven van n mogelijke sources naar 1 bestemming zou wel eens het kritische pad kunnen woiden 
m zwaar gcpipelmed^ processoren. Dit heeft als konsekwentie dat het lezen uit een register-file (hetgeen 
ook een n naar 1 transport is) of het voeren door een komplex bypass circuit weleens de cyclustijd kan 
gaan bepalen Behalve ontweipen voor een minimum aan data- en klok-skew, dienen zowel de grootte van 
de register-Ji/e als de grootte van de bypass te worden beperkt. Zoals reeds aangegeven. is de MOVE- 
architectuur supeneur wat betreft het beperken van het aantal benodigde registers. Het bypass circuit is 
vervangen door het transport netweric en het aantal verbindingen binnen het netweric is veel minder in 
vergehjkmg met een VUW architectuur. Het is onzc overtuiging dat wanneer transport het kritischepad 
wordt in de cyclustijd, de MOVE-aichitect uur geen reele concurrentie heeft nscnepaa 

Het gehraik van een dn^>er boom, beperkt de tijd tot #(/os(„)) . Een boom is echter veel moeiUjker te bedraden in VlJl. 
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Scheduling-vrijheid De prestatie van een VLIW is op cniciale wijze afhankelijk van de kwaliteit van 
scheduling van de code. In de MOVE-architectuur is een typische YLIW-RISC-operatie gesplitst in 66n 
of meer data-transport operaties (moves genoemd). Een 3 operand RlSC-instruktie, bijvoorbeeld, komt 
oveieen met 3 moves; een voor het transport van de eerste operand (operand-move), 66n voor het transport 
van de tweede (en laatste) operand (trigger-move) en 66n om het resultaat van de operatie te transporteren 
naar het uiteindelijke doel (result-move). De instmktie die de laatste operand transporteert, venx>raaakt 
ook het opstarten van de operatie (trigger). In combinatie met hybhde-pipelines (zie 3.2) in FUs» deze 
opsplitsing in transport komponenten verooizaakt nieuwe vrijheidsgraden voor scheduling die nog niet 
ecrdcr vcrtoont zijn. Zowel het transport van operanden als van resultaten zijn losgekoppeld van het 
transport van /rig^er-operanden. Het splitsen van een traditionele instruktie in zijn transportkomponenten 
heeft verschillende voordelen: 

1. Het elimineren van gemeenschappelijke subexpressies (CSE) kan worden toegepast op het transport 
van operandert Indien een operand niet verandert tussen twee operaties die gebruik maken van de 
zelfde FU, hoeft deze operand slechts een keer naar de FU getransporteerd te worden. 

2. Het verwijderen van onnodig transport naar general-purpose-registers doordat een resultaat niet dinekt 
geconsumeerd hocft te worden. Wannccr, bijvoorbeeld, de tweede operand voor een operatie nog 
niet beschikbaar is moet de eerste operand bewaard worden in een general-purpose-register. Mits 
de FU die deze operand produceert niet onmiddelijk nodig is, kan binnen de MOVE-architectuur dit 
bewaren ook gebeuren in deze FU zelf door de operand-move uit te stellen. 

3. Het verkrijgen van bete re initiatie-intervallen in softi^f are-pipelined-loops. 2k>a]s opgemerkt in [17] is 
het vaak wenselijk om vertragings-A-ra^es toe te voegen in pijpe/me-reserveringstabellen om optimale 
initiatie-intervallen te kunnen veikrijgen. Voor de MOVE betekent dit, dat het transport vanuit een 
resultaat-register vertraagd dient te worden. Ook hier geldt dat dit slechts kan voor die FUs die niet 
op voile snelheid gebniikt worden. 



Code grootte De verschuiving van CISC naar RISC vcroorzaakte een veigroting van de object-code van 
ongeveer 50%. Deze vergroting is acceptabel gezien 1) de capaciteitsvergroting van RAMs en 2) het 
gebmik van grote instruktie caches ter compensatie van het gesiegen instmktieverkeer. Het gebruik van 
VLIW architecturen kan echter gemakkelijk leiden tot een code explosie vanwege 1) het (gemiddeld) grote 
aantal ongebruikte operatie-.f/o/s en 2) de code duplicatie vereist voor geadvanceerde compiler technieken. 
In principe zijn MOVE-instrukties zelfs minder compact dan de vergelijkbare RISC-instrukties. Immers 
een 3-operand RISC-instruktie vertaald in drie moves. In ons MOVE-prototype, een MOVE-instniktie 
kost 16 bits, hetgeen neeikomt op 48 bits voor drie moves of 50% extra instnikties. Gelukkig zijn er 
verschillende redenen waarom deze 50% een bovengrens is, die gemiddeld genomen veel lager uitvalt: 

1. Veel moves transporteren data van FU naar FU. In het ideale geval verooizaakt dit 1.5 move per 3 
operand RISC-instruktie; een code reductie van 25%. 

2. Er zijn instnikties met minder dan drie operanden (branch/junip/monadische). 

3. Het elimineren van gemeenschappelijke subexpressies (CSE) verwijdert ook onnodige operand moves. 

Metingen met behulp van onze prototype-compiler, welke slechts scheduling op basic-block-mvcdsa mX- 
voerde zonder CSE, laten zien dat voor een aantal grote benchmarks het gemiddeld aantal moves per 
RISC-instniktie ongeveer 2.2 is. De volgende versic van de compiler zal hoogst waaischijnlijk de RISC- 
instmctiedichtheid evenaren. Wij verwachten dat met betrekking tot code dichtheid, dc MOVE-architectuur 
vergelijkbaar of zelfs beter is dan een RISC. 

Vergeleken met een VLIW- de MOVE-architectuur is superieur met betrekking tot code dichtheid. Al- 
lereerst is het aantal ongebruikte instructie slots gereduceerd vanwege het 5/iared-transport netweik (zie 
sectie 3) en ten tweede, is het mogelijk om volledige lege instnicties te vermijden met behulp van pipeline- 
blocking (hetgeen essentieel is voor scalaire code). 

9 1 0 0 5 9 8 

_910059eA_L> 



11 



10 



15 



20 



25 



30 



35 



40 



45 



Scalar en vector toepasbaarheid De MOVE-architectuur is ontworpen om uitbreidbaaiheid in aantal ea 
type FUs mogelijk te maken. In combinatie met de bijna onbepeikte mogelijichcden voor bet implementercn 
van FUs en het efficiente gebniik van het data-transportnetweiic is de MOVE-architectuur uiteimate geschikt 
voor het gebruik in vector en andeie speciale toepassingen. E6n van de problemen van veel vector machines 
IS de onbalans tussen de vector en de scalaire prestatie. Amdahl's wet bepeikt daarom de bniikbaaiheid 
van deze machines voor algemene vector toepassingen. VLIW architecturen gecombineerd met slimmc 
compilers zijn m staat om de prestatie van zowel vector als scalaire code te veibeteren Alhoewel de 
prestatie veibrtering voor scalaire code bepeikt is tot cen factor van 2 i 4. 

De MOVE-architectuur veibeterd cen standaani VLIW in 2 aspecten. 1) zoals ree^s gezegd. dc code 
uitbreidmg is minder diamatisch en 2) extra FUs kunnen makkelijk toegevoegd woiden zonder dat venm- 
denngen «" "et t^sportnetwerk vereist zijn en zonder dat het instnictiefonnaat verandert dient te woidea 
In standaard \UWs worden minder gebniikte functies gecombineerd in een enkele FU (bijv. integer, logic 
^rZ^ \ n ^^^.'T"'" ^ ft-<^«- -iden gescheiden zonder veel kosten (alfeen eS 
operand latches). Deze schc.ding hccft tot gcvolg dat deze fimcties ook parallel gcbruikt kunnen woiden 
en daardoor tot een prestatie veibeteiing leiden voor de scalaire perfonnance. 

Vei^geleken met e«i RISC-processor lijkt het net alsof de MOVE-architectuur een inherem nadeel voor 
scalaire code heeft Zoals getoond in figuur 5, ontstaa, tussen twee afhankelijke operaties een ^ 
komKn r-'^t *"''k ^f"'^" " i^o^^ccli^ld werk per instmctie veigelijkba^ propagX dc^ 
koB^matonsche logica en het latchen van het resultaat (zie sectie 4.2). Het verschil ligt hem i^ het feit Z 
de MOVE-arctatectmir twee maal latched inplaats van 6en maal (meteen na de logica, en meteen m, hS 
^sport). DC FU-resultaaf/aj,, kan echter wel gecombineenl woiden met combiStorischTfS^aTdiS 
gebnnk te maken van Earl of Polarity-hold latches). 

Het is ook mogehjk om het aantal cycli te venninderen op de zelfde manier als in een RISC door het 
IS. ThT^'^ ^'^^--i^rcA (zie figuur 6). Deze laatste opiossing voor de lost^cle if^hter^g^nl 
S ! ^ T" ^ 7''''^^ minimaliseren en nuttige moves the plaatsen in de lost-cycU. utus 
Z^J^^r, . 7""^^" "^P"'^'^'^ implementeren en zodoende een betere 

vulgraad voor deze lost-cycli te vericrijgen. Al met al. verwachtcn wij dat een MOVE-pmcessor met twee 
moves per mstractie reeds beter presteert dan cen standaaid RISC processor met twee 



processoren 



4.3 Toepasbaarheid voor het ontwerpen van applikatie-specifieke 

^^^uZZ^trZ?^'"^'''^^^''"^' ^"^'""^ ^^^"^"^ gepai^metrizeerde 

. H . ^^"^^"^ ^ processor een reele mogelijkheid. Een processor 

uitSwhn rT 'tr'^'''^ ^P^^fi-"^- toepassingen indien de aichitectuur zowel flexibe^ als wel 
uitbreidbaar is en het ontwerpen eenvoudig is. 

Flexibiliteit Het retargeting's proces vereist dat de functionaliteit flexibel te wijzigen is. VLIWs hebben 
hier een du.dehjk nadeel; het toevoegen van FUs behelst: 1) het venmderen van it Ltructieforaa^t^ 
het toe^gen van extm bussen (hctgeen de volledige register-filelayoutvcr^d.rt). De MOVE°Sel2 

'^tarvr^pTaek^^r-""^ ^^"^^"^^ - 

"fv^ de wil'^^ mogelijkheid tot het op eenvoudige wijze veranderen en aanpas- 

sen van de fimrtionaliteit is het van mtzonderiijk belang dat de prestatie aan te passen is aan de eisen van 

fsV^Z^k ' '^^yET^iir "^'^ '''' '""''^ vrijheidsgraad; behal^e het tLZ^L Z^,, 
L^r^ f T "^"•^'^ Uansportcapaciteit te vergroten. Het transportnetweric kan bijvoorbeeld 
geunplementeeRl worden met behulp van een aantal paiaUelle bussen die gegenereerd worden door nara- 
metnzeeH,are VLSI bibliotheekcellen. Het toevoegen van een bus is eenvo^^. alho^wZ^ 
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het instnictiefonnaat verandert. Deze verandering is eChter vborspelbaar en daardoor ook eenvoudig in de 
compiler door te voeren (bijvoorbeeld het aantal move bussen als compiler parameter). Het veranderen 
van de pipeline'gt2tsid is een andere manier om de piestatie aan te passen. 

• 

3 Ontwerptijd Bij het ontweipen van ASPs speira twee kwesties een belangnjke rol: de piestatie-kosten 
verhoiiding en de ontwikkel-tijd (time to market); Ontwerptijd is van cniciaal belang voor beide kwesties. 
Een lange ontweiptijd veroorzaakt hoge ontwerpkosten en een lagere performance omdat het ontweip op 
verouderde technologie wordt gebaseerd. Het aantal ontweip bepeikingen dat inherent door de MOVE- 
architectuur wordt ppgelegd is echter bijzonder laag; het veranderen van FU$> het toevoegen van FUs 
10 en het veranderen van het transportnetwerk kan allemaal onafhankelijk van elkaar gedaan worden. In 
onze oveituiging is de MOVE-architectuur ideaal voor het snel genereren van ASPs, gebniik makend van 
bestaande VLSI ontweipomgevingen. 
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5 Conclusies 

1. Een architectuur van een Centrale Processor Unit (C3>U) waaibij data-tr^ort van-openmden en 
alle of de meest belangrijke. operaties op deze operanden ontkoppcld zijn. De opcraties op ope- 
randen woiden veizoigd door zg. fimctie-units (FUs); het data-transport vindt plaats over een data- 
teansportnetweiic. Programmering van deze architectuur vindt plaats d.m.v. het spedficeren van 

5 data-tnmqwrtoperaties. Per instnictie wordcn 1 of meeidere van deze transportoperaties gespcdfi- 

ceeid. ledeie transport operatic spedficccrt €6n source en €6a of meerdere bestcmmingen. 

2. Een arcWtectuur zoals gespccificeerd onder conclusie 1. waarWj voor het data-transpoit een hierar- 
dusche busstructuur gebniikt woidL 

3. Een architectuur zoals gespedficeerd onder condusie 1. waarbij de data-transport operaties conditi- 
10 oneel worden uitgevoeid. r ^nuiu 

4. Een architectuur zoals gespedficeerd onder conclusie 3. waarbij de condities gespedficeerd worden 

door 1 of meerdere guards. 

5. Een architectuur zoals gespedficeerd onder condusie 4, waaitij de spedficatie van de guards on- 
derdeel vonnt van de spedficatie voor de data-transport operaties. 

6. Een architectuur zoals gespccificeerd onder conclusie 5. waarbij de spedficatie van het gebruik van 
de guards utt boolean-expressies bestaat, met in deze expressic de spedficatie van 1 of meerdere 
gu&rQs. 

7. Een architectuur zoals gespedficeerd onder condusie 1, waarbij het data-transport geimplcmenteerd 
IS d.m.v. smgle-cycle data-transport instnicties. ^ t. v «.h=c™ 

8. Een architectuur zoals gespedficeerd onder condusie 1. waaittj het data-transport gepipelined 
germplementeeid is. Het data-transport is hiert,ij gescheiden in een Ls cyclus eTZ^^lS^Jc^? 

9. Een architectuur zoals gespccificeerd onder condusie 1. waarbij het data-transpoit geimplementeerd 
wordt door m.ddd van een combinaUe van 1. 2 of meerder cycli data-transport operatief. Ee^S- 
t^port ^raue van 3 of meerdere cycli bestaat uit een lees cyclus 1 of meerderc transport cycli. 
«! 1 schnjf cydus. Data-transportoperaties geiinplementeerd d.m.v. meerdere cycli woiden gebniikt 
om clusters van fiinctie-umts met elkaar te laten communiceren. s ™« 

10. Een architectuur zoals gespedficeerd onder condusie 1. waarbij het transport-netwerk er^of <56n of 
meerdere FUs met selftimed logica zijn geimplementeerd. 

30 architectuur zoals gespedficeerd onder condusie 1. waarbij voor ddn of meer functie-muts een 

JO zg. hybrid pipeline sdiema wordt gebniikt. 

12. ^n architectuur zoals gespedficeerd onder condusie 1. waarbij «n of meer fimctie-units geunple- 
menteerd zijn m.b.v. wave pipelining. ^ ^ 

^cZc'-'^^^r «»^'^g^Pf ifi<=««rd onder conclusie 11 of condusie 12. waarby ten behoeve van 
exccpties een of meerdere fimctie-units zijn uitgcmst met uitloop registers. Deze fimctie-units zijn 

Tl .""^''"^ "^1 ''^ ^""^^^ tenigkeer vanuit een exceptie worS 

Ujdens het lezen van resultalen uit deze fimdie-units automatisdi eerst de uidoop registers gelezen. 

14. Een architectuur zoals gespedficeerd onder conclusie 1. waarttj predese-excepties worden onder- 
steund d.m.v. het zg. inexact exceptie mechanisme. 

^hi|f'^t"«';«'als gespccificeerd onder condusie 1, waaAij tijdens het lezen vanuit een fimdie- 
umt van «sn ruet-precies exceptie resultaat niet direct een exceptie gegcnereerd wordt. dodi waarbij 
de exceptie als extra conditie met de data over het transport netwerk mee propageert. Op een late.^, 
door de compiler bepaaldtijdstipkan deze exceptie woiden afgehandeld. 
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16. Een architectuur zoals gespecificeerd onder conclusie 1, waarblj binnen 1 cydus de juiste exceptie- 
vector wordt bepaald. Hierbij woidt het transport identificatie-nummer van die transport operatie die 
een exceptie veroorzaakt gebniikt voor deze bepaling. 

17. Een architectuur zoals gespecificeerd onder conclusie 16, waarbij niet geunplementeerde fiinctiona* 
5 liteit d.m,v. een emulatie mechanisme wordt geemuleerd. 

18. Een architectuur zoals gespecificeerd onder conclusie 1, waarbij het transport netweik automatisch 
blokkeert zolang 1 van de data-waarden die getranporteerd dienen te worden, nog niet door de fiinctie- 
unit, die deze waarde berekent, geleverd kan worden, omdat de berekening van deze data-waarde 
nog niet voltooid is. Zodra deze beiekening voltooid is wordt de blokkering opgeheven. 

10 19. Een architectuur zoals gespecificeerd onder conclusie 1, waarbij een functie-unit waamaaar een 
data-waarde getransporteerd dient te worden, het data^tranpoit netweik blokkeeit» zolang hij deze 
data-waarde nog niet kan verweiken, 

20. Een architectuur zoals gespecificeerd onder conclusie 1, waarbij de instructie-unit zich als een stan- 
daard functie-unit gedraagt, d.w.z. gelijk aan de meeste overige functie-iinits. De operanden van deze 

15 functie-unit» het instructie-register en de programma teller zijn via het data-transport netweric toegan- 

kelijk. Immediate data-waarden kunnen dircct uit het instnictie-register worden gelezen. Het tranpoit 
netwerk wordt beheerd door een z.g. buscontroler, deze heeft toegang tot het instructie-register en 
de programma teller via het data-transport netwerk of via een separaat transport netweik. 

21. Een architectuur zoals gespecificeerd onder conclusie 1 en conclusie 20, waaibij meerder instructie- 
20 units aanwezig zijn en met het data-transport netwerk zijn verbonden. De buscontroler kan instnicties 

nit meerdere instructie-rcgisters selecteren om deze te gebruiken voor de besturing van het data- 
transport netwerk. 
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Figure 1: Register-FU-bypass communicatie voor (super) pipelined en VLIW organisaties. 
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Figure 2: Maak de bypass zichtbaar op architectuur niveau. 
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Figure 3: Separeer transport van operaties. 
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Figure 4: Support-mcchanismcn voor de MOVE-architcctuun 



ADD Rl, R2, R3 R2 -> Radd-operand* R3 -> Radd-trigger 
SUB R4, R5, Rl 

Radd-result -> Rsub 

etc. 



Figure 5: Vergelijking van scalaire RISC- en MOVE-code 
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Rgure 6: MOVE architectuur zonder de "verlorcn cyclus". 
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